home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000114_owner-urn-ietf _Thu Nov 7 18:02:35 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  7KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA04045 for urn-ietf-out; Thu, 7 Nov 1996 18:02:35 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA04040 for <urn-ietf@services.bunyip.com>; Thu, 7 Nov 1996 18:02:31 -0500
  3. Received: from CS.BU.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA26943  (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 18:02:28 -0500
  5. Received: by cs.bu.edu (8.6.10/Spike-2.1)
  6.     id SAA28165; Thu, 7 Nov 1996 18:02:24 -0500
  7. Date: Thu, 7 Nov 1996 18:02:24 -0500
  8. Message-Id: <v02130500aea91f6a784f@[128.148.157.46]>
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset="us-ascii"
  11. To: urn-ietf@bunyip.com
  12. From: dgd@cs.bu.edu (David G. Durand)
  13. Subject: Re: [URN] I18N does not belong in URNs
  14. Sender: owner-urn-ietf@services.bunyip.com
  15. Precedence: bulk
  16. Reply-To: dgd@cs.bu.edu (David G. Durand)
  17. Errors-To: owner-urn-ietf@bunyip.com
  18.  
  19. At 4:09 PM 11/7/96, Keith Moore wrote:
  20. >Please accept that I agree with you here.  I don't want Internet
  21. >information access protocols to be significantly biased in favor of
  22. >English speakers (or anybody else).
  23. >
  24. >I say "please accept" because if you accept that we substantially
  25. >agree on the above, it's a lot easier to understand the rest of what
  26. >I'm saying.
  27. >
  28. >For the case of URNs, I have no problem with the idea that they should
  29. >not be friendly to English speakers -- because they really shouldn't
  30. >be freindly to anybody, except to be transcribable!
  31. >
  32. >On the other hand, we can hardly prohibit some rare and occasional
  33. >misuse of URNs such that human-friendly meaning creeps in.  And we've
  34. >long since established the need to grandfather in existing name spaces
  35. >that have the characteristics of URNs.  Some of those name spaces are
  36. >going to have some minimal human-friendliness, some degree of meaning
  37. >exposed in the names.  But there won't be much human-friendliness in
  38. >any name space that gets grandfathered in, as any naming scheme which
  39. >tries to embed lots of meaning in the names will inherently have poor
  40. >persistence and thus be unsuitable for URNs.
  41.  
  42. I am tired of your repeating this. I have pointed out that the URN space of
  43. ISO Formal public identifiers is human-friendly (to English speakers, and
  44. you can bet the revision will be to the rest of the world). Those
  45. identifiers are assigned according to rules that are supposed to guarantee
  46. uniqueness. As they are in common productive use in the SGML world (which
  47. certainly has a significant relationship to the WWW) is a reason that they
  48. will be grandfathered in.
  49.  
  50. So your assertion is simply _false_. So, now given that FPIs will be
  51. English-speaker friendly, and grandfathered into URN-space, what do you
  52. propose to do about it? I have worries about I18N becuase it seems to fail
  53. the transcribability test (for arbitrary transcribers) -- but I don't want
  54. to be a cultural imperialist, and I don't see any special virtue in ASCII
  55. other than omnipresence.
  56.  
  57.    Creating "unfriendly" namespaces may seem good practice to you, but I
  58. don't see how it can be mandatory, no matter how much you wish it to be so.
  59.  
  60. >I agree that it may be difficult to get most people to understand that
  61. >URNs are not human-friendly names (since it's been difficult to do
  62. >even within this WG).
  63.  
  64. I think it's an unreasonable requirement. That's why it's so hard to
  65. convince people of it.
  66.  
  67. >Perhaps the right thing to do is to define a mapping to be used when
  68. >grandfathering existing non-ASCII namespaces to URNs, i.e. to encode
  69. >the non-ASCII characters as UTF-8 and then encode each octet not
  70. >printable in ASCII using %XX notation.  That way, people could still
  71. >type in resource names like they're accustomed to doing, but the
  72. >program they type them in to would convert them to canonical URN
  73. >format (by prepending URN:namespace: and doing the UTF-8 and %XX
  74. >encoding).  For purposes of resolution, URNs would always be
  75. >transmitted in canonical format, but programs could decode the %XX and
  76. >UTF-8 for the purposes of display to humans.
  77.  
  78. So what does this get other than harder-to-debug network protocols? If we
  79. define a standard translation, and make sure that it's an equivalence
  80. relation (as seems to be required), then why not just transmit it the
  81. normal way. Once it can be seen in meaningful form, it _will_ be
  82. transmitted that way from human to human, regardless of any
  83. numericalization we try to impose.
  84.  
  85. >
  86. >There's probably more than one organization in the world named ICRC.
  87. >The one your brother works for got ICRC.COM first, but the name is
  88. >still ambiguous.  You could have as easily found the a different ICRC
  89. >than the one you were looking for.
  90.  
  91. But once the name is assigned, you will never get the other ICRC.COM, so it
  92. doesn't matter. Even if one of the ICRCs goes out of business, ICRC.COM
  93. will not be reassigned. So no problem! The ISO naming rules (simple
  94. hierarchy, with well known roots) already can ensure this.
  95.  
  96. >All names are unambiguous only within a limited context.  When the net
  97. >was small, the context was inherently limited, so it didn't cause a
  98. >problem to have only one host for any given name.  But now that the
  99. >net is much larger, it is a big problem.
  100.  
  101. The only context that matters is the policies that we set up of URN
  102. management. Once a subset of the namespace is assigned it can't be
  103. reassigned.
  104.  
  105. >Part of this is because you'll already be restricting the context of
  106. >the search -- if you're looking for the name of a business
  107. >organization, you'll go to a service that matches user-friendly names
  108. >against names of businesses.  If you're looking for a person's name,
  109. >you'll use a different service.
  110. If URNs are assigned to have the properties of URNs they will still be
  111. persistent. No-one is arguing that URNs should be designed to be
  112. meaningfully searched, just that they may be designed to be meaningfully
  113. remembered. If your memory fails or your attempt to deduce things from
  114. other names you have seen fails, then you just have to find the right name
  115. (maybe via some kind of directory search).
  116.  
  117.  
  118. Obscure names are obscure, but they are not any more reliable for that.
  119.  
  120.    -- David
  121.  
  122. _________________________________________
  123. David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
  124. Boston University Computer Science        \  Sr. Analyst
  125. http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
  126. --------------------------------------------\  http://dynamicDiagrams.com/
  127. MAPA: mapping for the WWW                    \__________________________
  128.  
  129.